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INTRODUCTION: 

NORDA'S  ROLE  IN  THE  DEVELOPMENT  OF  THE  WORLD  VECTOR  SHORELINE  PRODUCT 

One  of  the  most  basic  needs  in  Mapping,  Charting  and  Geodesy  (MC&G)  is  a 
global  shoreline  map.  In  FY85,  a  NORDA  study  of  naval  MC&G  data  requirements 
revealed  that  a  large  number  of  Navy  systems  currently  use  or  plan  to  use  a 
digital  shoreline  product.  In  August  of  1985,  OP-096  listed  the  Navy's  specific 
requirements  for  such  a  product,  which  included  the  following  (Langran  and 
Connor,  1986): 

-  shoreline  data  must  support  a  high  resolution  at  a  scale  of 
1:250,000 

shoreline  and  boundary  vectors  must  be  cross-referenced 
data  structure  must  promote  automatic  data  entry  and  display 

-  data  structure  must  allow  automatic  identification  of  land 
and  water  sides  of  the  shorelines 

data  structure  must  allow  automatic  identification  of  countries 
on  either  side  of  political  boundaries  and  indicate  disputation 
status  of  boundaries 

Digital  (or  computer-generated  and  displayed)  maps  are  not  new  to  the  MC&G 
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an 


"community;  the  Central  Intelligence  Agency's  (CIA)  World  Data  Bank-II  (WDB  II), 
which  has  been  the  unofficial  standard  digital  shoreline  product,  was  first 
distributed  over  twelve  years  ago.  WDB  II,  however,  would  not  satisy  Navy 
requirements  for  several  reasons,  including  scale  restrictions,  lack  of 
geographic  information,  and  division  of  file  boundaries. 


Figure  1.  Shorelines  of  the  Northern  Black  Sea  (Odessa) 


WDB  II  is  an  excellent  base  for  small  scale,  simpler  shoreline  maps,  but  it 
is  not  accurate  enough  for  the  Navy's  growing  needs.  WDB  II  was  digitized  at 
scales  ranging  from  1:1  million  to  1:4  million,  with  an  average  scale  of  1:3 
million,  or  .02  inches/nautical  mile  (CIA,  1977).  The  Navy  requires  a  scale 
of  about  1:250,000  or  better  (about  .29  inches/nautical  mile).  Figure  1 
presents  a  comparison  of  these  two  databases  with  plots  of  the  Odessa  region 
and  the  Northern  Black  Sea.  In  addition  to  differences  in  scale,  WDB  II  stores 
only  the  simple  (x,y)  coordinates  of  shorelines  and  political  boundaries,  while 
the  Navy  requires  a  dataset  that  would  also  define  and  store  relatively  complex 
geographic  relationships.  Finally,  WDB  II  is  distributed  in  land-based  files 
(North  America,  South  America,  etc).  Navy  users  would  naturally  find  ocean- 
based  files  more  readily  applicable  to  their  needs. 

In  FY86,  the  Defense  Mapping  Agency  (DMA)  developed  a  prototype  for  a  new 
digital  World  Vector  Shoreline  (WVS)  product  that  included  political  boundaries 
and  country  names  with  the  shoreline  vectors.  The  source  of  WVS'  shorelines  is 
DMA's  Digital  Land  Mass  Blanking  (DLMB)  dataset,  a  raster  land  mask  gridded  at 
3  arc-second  intervals,  derived  from  nautical  charts  and  maps  with  a  scale  of 
1:250,000.  The  shoreline  vectors  were  produced  by  contouring  the  land/sea 
interface  of  DLMB;  political  boundaries  were  added  from  separate  sources  and 
have  an  average  scale  of  1:1,000,000. 

DMA  sent  copies  of  the  prototype  to  four  Navy  groups,  including  N0RDA,  and 
requested  feedback  to  determine  whether  WVS  would  meet  the  Navy's  requirements 
for  a  digital  vector  shoreline  dataset.  In  response,  N0RDA  released  two 
reports  with  recommendations  on  the  database  itself  (Langran  and  Connor,  1986) 
and  on  the  format  in  which  it  was  stored  -  DMA's  Standard  Linear  Format,  or  SLF 
(Langran,  et.al,  1986).  As  a  result,  DMA  requested  that  N0RDA  assist  them  in 
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designing  a  new  WVS  format  to  be  certain  the  Navy's  needs  were  met.  The  new 
format  and  data  structure  were  completed  in  February  of  1987  (Lohrenz,  ly88). 

In  FY88,  NORDA  again  assisted  DMA  in  the  production  of  WVS:  NORDA 
developed  a  software  package  to  convert  input  digitized  vectors  into  the 
WVS-specific  format.  This  software  was  completed  and  tested  in  May  of  1988, 
in  time  to  meet  DMA's  planned  production  schedule.  To  date,  DMA  has  entered 
over  half  of  the  world's  shorelines  into  the  WVS  database,  and  the  entire  world 
is  scheduled  fcr  completion  by  the  end  of  this  fiscal  year.  Earlier  this 
fiscal  year,  NOKDA  proposed  to  develop  for  DMA  a  package  of  utility  software  to 
help  users  process  the  WVS  data  (read,  extract  windows,  compress,  plot,  etc.) 
This  proposal  is  still  under  consideration  at  DMA  for  FY89. 


WVS  FILE  DESCRIPTION 


General 


For  portability,  WVS  data  is  ASCII  coded  and  written  to  unlabeled ,  ANSI 
standard  magnetic  tapes.  Records  in  the  file  have  a  fixed  length  of  48  bytes 
and  are  blocked  by  200  on  tape  for  a  standard  block  size  of  9600  bytes.  The 
file  begins  with  four  header  records  that  provide  general  file  information 
(edition  number,  compilation  date,  origin  of  the  map,  number  of  features  and 
segments  in  the  file,  etc.).  Following  the  file  headers  are  text  records 
(giving  any  additional  information  specific  to  this  file),  feature  records 
(providing  feature  identification  codes  and  listing  the  segments  belonging  to 
each  feature)  and  segment  records  (providing  the  actual  X,Y  data  records). 
Feature  and  segment  records  are  organized  and  stored  by  lxl  degree  cells,  as 
described  later  in  this  paper. 

Data  Content 

The  first  edition  of  the  WVS  dataset  contains  three  geographic  feature 
types:  shorelines,  political  boundaries,  and  country  names,  which  are  identified 
by  DMA's  Feature  Attribute  Coding  Standard  (FACS)  codes  of  2A010,  6Axxx,  and 
9A010,  respectively  (DMA,  1985  b).  Political  boundary  data  are  subcoded  from 
6A000  to  6A999  according  to  disputation  status  (e.g.,  established,  disputed, 
unknown,  etc.)  The  date  of  identification  (i.e.,  when  the  boundary  was 
established,  or  when  it  was  last  described  as  disputed)  is  also  stored.  Various 
file  attributes  are  given,  including  the  longitude  and  latitude  extremities  of 
the  file,  the  total  number  of  features  and  segments  in  the  file,  and  the  maximum 
number  of  vertices  per  segment. 

Cell  Structure 


WVS  data  are  partitioned  into  lxl  degree  cells  that  wrap  the  globe 
sequentially  in  the  X  (longitude)  direction.  A  WVS  file  covering  the  globe 
contains  360  x  180  or  64800  cells  numbered  sequentially  from  1  to  64800:  the 
origin  of  cell  1  is  180  W,  90  S;  the  origin  of  cell  64800  is  180  E,  90  N.  Data 
are  collected  into  cells  to  facilitate  windowing,  repartitioning,  and  future 
expansions  of  the  data  set.  This  paper  provides  a  simple  algorithm  to  determine 
the  cell  number  of  any  input  point  (longitude,  latitude),  which  facilitates  the 
collection  and  display  of  WVS  data  for  any  desired  geographic  area. 

WVS  feature  and  segment  records  (including  the  actual  X,Y  data  points)  are 
stored  by  cell  number  in  the  file.  At  the  start  of  a  new  cell,  a  cell  header 
record  provides  the  number  of  features,  number  of  segments,  number  of  feature 
records,  and  number  of  segment  records  in  that  cell.  Following  the  cell  header 
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record  are  all  the  feature  records  for  that  cell,  followed  by  all  the  segment 
records  and  X,Y  points  for  that  cell. 

Data  File  Structure 


The  WVS  file  structure  was  designed  to  minimize  redundant  data  storage. 

Since  a  sequence  of  vertices  (from  here  on  referred  to  as  a  segment)  may  outline 
more  than  one  feature,  features  are  cross-referenced  to  their  segments  (and  vice 
versa)  via  unique  alphanumeric  feature  and  segment  keys.  In  this  way,  a  segment 
that  is  shared  by  more  than  one  feature  is  stored  only  once.  The  segment  header 
record  contains  a  list  of  each  of  the  features  that  the  segment  delineates. 
Likewise,  each  feature  in  the  map  file  is  stored  only  once.  The  feature  data 
record  c  itains-  a  list  of  each  of  the  segments  that  delineate  that  feature. 

This  method  of  data  storage  was  also  utilized  in  SLF  and  is  referred  to  as 
"chain-node”  (DMA*,  1985  a).  In  sum,  one  feature  may  be  comprised  of  many 
segments,  or  one  segment  may  delineate  several  features,  but  in  either  case, 
each  segment  and  feature  is  stored  only  once  in  chain-node. 

To  support  advanced  uses,  all  WS  segments  define  which  feature  types  lie 
to  the  left  and  to  the  right  of  a  segment  (when  moving  forward  through  its 
vertices).  For  example,  the  left  side  of  a  shoreline  segment  may  be  land  and 
the  right  side  water.  For  boundary  segments,  the  countries  lying  to  the  left 
and  right  are  designated.  For  "left"  and  "right"  to  have  any  relative  meaning, 
the  order  of  vertices  within  a  segment  for  a  given  feature  must  be  provided. 

In  describing  a  particular  feature,  WVS  assigns  a  directional  indicator  (most 
commonly  used  are  "F"  for  forward  and  "R"  for  reverse)  to  each  of  the  segments 
delineating  that  feature.  Thus,  if  a  segment's  vertices  are  to  be  read  in 
reverse  of  the  order  in  which  they  were  stored,  the  direction  would  be  "R". 


SEQUENTIAL  DATA  STORAGE 


CHAIN-NODE  DATA  STORAGE 


(A)  FEATURES  ON  A  MAP 


(D)  DIGITIZED  SEGMENTS 


(B)  DIGITIZED  POLYGONS 


(E)  INDIVIDUALLY  DISPLAYED  WVS  FEATURES 


(C)  DISPLAY  OF  DATA  STORED 
SEQUENTIALLY 


5 


(F)  DISPLAY  OF  DATA  STORED  IN 
CHAIN-NODE  STRUCTURE 


Figure  2.  Sequential  vs.  Chain-node  Data  Storage 
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Figure  2  shows  the  basic  differences  between  conventional  ’’sequential" 
data  storage  and  chain-node  data  structuring,  together  with  this  directional 
capability.  Figure  2  (a)  shows  three  adjacent  areal  features  as  they  might 
appear  on  a  map.  In  the  sequential  storage  method,  each  feature  would  be 
treated  as  a  separate  polygon,  digitized  independently  (b),  and  stored  as 
a  string  of  (X,  Y)  coordinates.  The  common  boundary  between  two  abutting 
features  would  be  digitized  twice,  and  the  two  versions  may  not  coincide. 

This  often  results  in  gaps  or  overlaps  along  the  boundary  (c). 

In  the  chain-node  method,  the  segments  that  comprise  the  features  are 
digitized  .independently  as  shown  in  Figure  2  (d).  The  common  boundary  between 
adjacent  features  is  digitized  and  stored  only  once,  so  that  the  features  abut 
precisely.  "The  coordinates  of  each  segment  are  stored  with  a  unique  segment  ID 
number  and  a  list  of  the  features  associated  with  that  segment.  Likewise,  each 
feature  is  stored  with  a  unique  ID  and  a  list  of  the  segments  (with  directional 
indicators)  that  define  it.  Therefore,  features  may  be  displayed  either 
separately  (e)  or  together  (f)  with  no  overlaps  or  gaps  along  the  boundaries 
between  them. 


METHODS  OF  ACCESSING  WS 


Determining  Cell  Codes  for  Extracting  Windows  of  Data 

The  number  of  the  geographic  cell  in  which  any  point  (Xn,  Yn)  is  located 
may  be  determined  with  the  following  algorithm: 


CELL  CODE 


where  INT 
ABS 

CELL  CODE 
Xn 
Yn 
Xo 
Yo 
XCELL 
YCELL 
XMAP 


1  +  (  INT(ABS(Xn  -  Xo)  /  XCELL)  ) 

+  (  INT(ABS(Yn  -  Yo)  /  YCELL)  *  (XMAP  /  XCELL)  ) 

indicates  truncation  to  integer 

indicates  absolute  value  (both  are  functions  in  the 

standard  Fortran  77  library) 

number  of  cell  to  be  found 

longitude  of  the  point  in  question 

latitude  of  the  point 

longitude  of  the  map  origin  (LONGOR,  in  File  Header  #2) 
latitude  of  the  map  origin  (LATOR,  in  File  Header  #2) 
width  of  cell  in  degrees  longitude  (in  File  Header  #4) 
height  of  cell  in  degrees  latitude  (in  File  Header  #4) 
width  of  the  map  in  degrees  longitude  (in  File  Header  #2) 


In  WVS,  the  following  values  may  be  substituted  in  the  above  equation: 

Xo  =  -180  deg,  Yo  =  -90  deg,  XCELL  =  YCELL  =  1,  and  XMAP  =  360.  The  algorithm 
for  determining  the  number  of  the  WVS  cell  in  which  any  point  (Xn,Yn)  resides 
is  therefore  as  follows: 


CELL_C0DE  =  1  +  INT(ABS(Xn  +  180))  +  INT(ABS(Yn  +  90)  *  360) 

Rectangular  subsets  or  windows  of  the  WVS  file  may  be  selected  by  extracting 
and  aggregating  cells  of  data.  Determine  the  cell  numbers  for  the  upper  and 
lower  longitude  and  latitude  boundaries  of  the  window  first  (using  the  above 
equation),  then  simply  fill  in  the  rest  of  the  area's  cell  numbers.  If  the 
window  is  to  be  selected  directly  from  tape,  the  cells  must  be  accessed 
sequentially,  as  described  in  the  following  section.  A  faster,  direct  access 
method  is  also  described  for  those  who  will  store  their  WVS  data  on  disk. 
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Sequential  Access 


To  access  cells  of  WVS  data  from  a  tape  or  other  non-random  access  device, 
a  user  must  sequentially  read  through  the  file  and  pull  out  the  desired  cells 
of  data,  as  follows: 

1.  Compute  the  numbers  of  the  cells  needed  for  the  desired  geographic  area 
^  using  the  algorithm  given  in  this  paper. 

2.  Starting  at  the  top  of  the  file,  read  each  record.  When  a  cell  header 
is  encountered,  read  the  cell  number  to  determine  if  it  is  one  of  the 
required  cells. 

3.  If  the  cell  is  required,  collect  its  data.  Otherwise,  use  -the  feature  and 
segment  record  counts  in  the  cell  header  to  quickly  skip  all  the  records 
in  that  cell  (to  the  next  cell  header). 

4.  Repeat  steps  2  and  3  until  the  contents  of  all  required  cells  have  been 
recovered . 

Direct  Access 

Tf  the  WVS  file  can  be  loaded  onto  a  disk  or  other  media  allowing  rapid 

direct  access,  this  method  is  faster  than  the  sequential  access  method  to 

recover  data  for  specific  cells: 

1.  Create  a  look-up  table  that  lists  the  number  of  each  cell's  first  record 

(i.e.,  the  cell  header  record)  in  the  WVS  file.  Record  1  in  the  look-up 

table  points  to  the  location  of  Cell  1,  Record  2  to  Cell  2,  etc.  The 
look-up  table  need  only  be  created  once,  when  the  file  is  initially  loaded 
from  tape. 

2.  Compute  the  numbers  of  the  cells  required  for  the  specified  geographic  area 
using  the  algorithm  given  in  this  paper. 

3.  Access  the  look-up  table  by  cell  number,  access  the  cell  header,  and  collect 
the  cell  contents.  For  further  illustration,  see  Table  1.  Repeat  this  step 
until  the  contents  of  all  required  cells  have  been  recovered. 


Sample 

Look-up 

File 


1 

122 

345 

908 

1609  <-- 

2099 

3437 

3678 

4980 

5002 


Table  1.  Using  a  Cell  Table  Look-up  File 
Example:  Collect  the  contents  of  WVS  cell  #5: 

a)  Find  the  starting  WVS  record  number  of  cell  #5: 

READ  (ITABLE,REC=5)  NREC 

where  ITABLE  is  the  logical  unit  number  (LUN) 
assigned  to  the  table  look-up  file,  and  NREC  is 
the  starting  record  number  of  cell  #5  in  the  WVS 
file;  in  this  example,  NREC  =  1609. 

b)  Access  the  first  record  (the  header  record)  of  cell  #5: 
READ  (IWVS,REC=NREC)  CELLHEADER 

where  IWVS  is  the  LUN  assigned  to  the  WVS  file 
and  CELLHEADER  is  the  48-byte  cell  header  record. 

c)  Read  and  process  the  feature  and  segment  records  (which 
directly  follow  the  cell  header  record)  for  cell  #5. 
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USERS'  COMMENTS  ON  WS 


This  section  presents  users'  comments  on  the  WS  database,  based  primarily 
on  responses  to  the  questionnaire  that  was  distributed  in  March  1987  with  the 
prototype  WVS  data  set.  Some  information  has  also  been  drawn  from  papers  that 
were  presented  at  this  year's  Third  Naval  Digital  MC&G  Interest  Group  meeting, 
organized  by  the  Navy's  Digital  MC&G  Analysis  Program  (DMAP).  The  discussion  is 

divided  into  three  main  topics:  User  Background  (including  system  constraints 

such  as  memory,  data  storage  and  file  access),  WS  Applications  (current  and 
planned)  and  Future  WS  Requirements.  A  more  detailed  look  at  the  reseults  of 

the  1987  WS  survey  and  a  copy  of  NORDA's  questionnaire  may  be  found  in  Lohrenz 

(1988). 

User  Background  and  System  Constraints 

Over  fourteen  different  computer  systems  were  represented  by  the  users  who 
responded  to  NORDA's  WS  questionnaire  in  1987.  The  number  of  bits  per  word  in 
these  systems  ranged  from  8  to  60.  This  disparity  points  out  the  importance  of 
standardization  in  databases  such  as  WS.  The  more  Navy  computers  that  can 
easily  incorporate  the  database,  the  more  useful  that  data  base  will  be  to  the 
Navy.  For  example,  users  preferred  ASCII  to  binary  for  the  distributed  WS 
database,  even  though  binary  data  would  take  up  less  storage  space  than  ASCII. 
Different  computers  store  binary  data  differently,  but  ASCII  is  a  standard  data 
storage  format  used  by  most  modern  computers  and  is  easily  input  by  all  Navy 
computer  systems. 

The  most  critical  system  constraints  cited  were  the  following:  size  of 
system  and  display  memory,  disk  storage,  and  display  generation  time.  One 
respondent  also  mentioned  array  dimensioning  (for  storing  segment  vertices)  as 
a  potential  problem.  Array  dimension  limitations  would  impact  the  number  of 
vertices  that  the  computer  could  store  for  a  single  WS  segment. 

The  method  of  data  storage  used  by  WS  (i.e.,  1-degree  cells)  reduces  the 
chance  that  a  segment  array  will  become  too  large,  since  segments  are  split  into 
smaller  units  along  cell  boundaries.  Constraints  on  system  and  display  memory 
and  disk  storage  are  also  minimized  by  the  use  of  data  cells:  if  only  certain 
cells  are  required  for  a  particular  application,  then  only  those  cells  need  to 
be  copied  from  the  distribution  tape  onto  disk  and  displayed.  If  the  whole 
world  is  needed,  and  memory  or  storage  is  limited,  filtering  should  be  done  to 
reduce  the  size  of  the  data  set.  All  respondents  liked  the  lxl  degree  cell 
method  of  data  storage  for  another  reason  as  well:  they  found  it  very  valuable 
in  speeding  up  data  access,  and  therefore  display  generation  time,  particularly 
in  geographic  windowing  applications. 

Data  access  can  also  be  accelerated  by  directly  accessing  WS  data  with 
a  cell  table  look-up  file,  as  described  in  this  report  and  in  the  WS  users' 
guide.  Users  at  NOSC  and  NUSC  have  successfully  implemented  this  direct  access 
method,  liked  it,  and  went  on  to  adapt  it  to  other  functions  such  as  feature 
extraction.  Other  users  were  planning  to  try  the  direct  access  method  in  the 
future.  Meanwhile,  they  found  the  sequential  access  method  easy  to  implement. 

Overall,  automated  "one-pass"  data  entry  was  successful.  Users  reported  that 
the  ease  of  data  entry  was  significantly  improved  by  the  inclusion  of  record 
counts,  feature/segment  counts,  other  file  and  cell  header  information,  and 
thorough  documentation. 

Due  to  data  storage  limitations,  most  users  said  they  would  like  DMA  to 
provide  the  WS  data  set  at  than  one  data  density  (resolution).  Systems 
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with  severe  data  storage  limitations  would  be  unable  to  store  the  entire,  high 
density,  data  set  on-line.  Providing  users  with  several  WVS  resolutions  would 
also  ensure  a  higher  degree  of  compatibility  between  systems  that  will  filter 
their  data,  since  they  could  start  filtering  at  the  data  density  closest  to 
their  need  (instead  of  always  starting  from  the  maximum  WVS  data  density). 

At  the  time  of  the  survey,  all  respondents  used  or  planned  to  use  a  critical- 
point  data  filter. 

WVS  Applications 

All  programs  surveyed  in  1987  planned  to  use  VVS  as  a  base  map  on  which  to 
overlay  other  data.  Digital  Terrain  Elevation  Data  (DTED)  and  Digital  Feature 
Analysis  Data  (DFAD)  were  listed  most  frequently  as  the  data  to  be  overlayed  on 
WVS.  Other  data  types  mentioned  include  bathymetric  contours,  Hydrographic 
Obstruction  Data  (HOD),  cartographic  data,  and  miscellaneous  others.  In  this 
year's  Naval  DMAP  meeting,  McCleary  and  Wescott  (1989)  describe  various  methods 
of  displaying  geographic  information  (such  as  VVS)  for  their  applications. 

Scale  requirements  for  WVS  varied  widely  in  the  1987  survey:  from  1:7,300 
(about  0.1  NM/inch)  to  nearly  1:33,000,000  (about  450  NM/inch).  Obviously, 
this  range  is  too  large  to  be  handled  by  the  current  WVS  scale  (1:250,000).  As 
mentioned  earlier,  users  would  find  it  helpful  if  DMA  provided  several  data 
densities  from  which  to  filter  to  the  resolution  and  scale  required.  In  any 
event,  it  should  be  noted  that  a  scale  of  1:7,300  is  unreasonable  for  a  global 
shoreline  data  set! 

Two  interesting  data  compression  methods  for  shorelines  were  described 
at  the  Naval  DMAP  meeting  this  year.  Sharman  (1989)  describes  a  fractal-based, 
resolution-dependent  data  compression  method,  which  he  terms  "excerpolat ion, " 
for  reducing  the  bulk  of  data  in  detailed,  vector-based  databases.  He  has 
applied  his  method  to  WDB  II  shoreline  vectors  but  not  yet  to  WVS.  It  would  be 
interesting  to  investigate  this  method  both  for  reducing  the  size  of  the  full 
resolution  WVS  database,  with  a  minimal  loss  of  information,  and  for  filtering 
VVS  into  diffcr-ft  resolutions.  Hammack  and  Pepper  (1°89)  describe  another 
suitable  data  compression  method  for  high-resolution  geographic  data  sets. 

They  have  successfully  applied  it  to  both  WDB  II  and  to  WVS  shoreline  vectors. 

All  respondents  to  the  1987  survey  used  or  planned  to  use  color  fills  on 
the  WVS  data.  Common  color  fill  applications  include  blocking  out  water  areas 
to  emphasize  land  features,  or  vice  versa,  and  shading  certain  countries  to 
point  out  various  political,  geographic,  or  other  relationships.  For  example, 
water  areas  could  be  colored  blue;  hostile  nations  may  be  red.  WVS  provides  a 
"flag"  in  each  cell  header  to  indicate  whether  that  cell  contains  all  land,  all 
water,  or  a  combination  (i.e.,  a  shoreline).  Users  indicated  that  these  flags 
would  be  very  useful  for  filling  in  land  and  water  areas. 

Similarly,  WVS  provides  a  flag  to  indicate  what  country  lies  to  the  left  and 
to  the  right  of  each  political  boundary.  None  of  the  respondents  needed  this 
information  currently,  but  several  foresaw  future  applications  for  it.  For 
example,  the  boundaries  of  France  could  be  easily  picked  out  of  the  data  set, 
since  each  of  its  boundary  segments  is  marked  with  a  "France"  flag. 

Future  WVS  Requirements 

Asking  users  to  identify  future  WVS  requirements  resulted  in  many  good 
suggestions,  most  of  which  follow: 

-  WVS  should  be  made  available  in  several  resolutions. 
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Feature  levels  (e.g.,  an  island  within  a  lake  within  a  continent)  should  be 
identified. 

Features  such  as  islands  should  be  ranked  by  size. 

-  Nodes  (segment  endpoints)  should  be  stored  explicitly,  and  should  include 
the  points  at  which  different  features  meet  (e.g.,  where  a  political 
boundary  meets  a  shoreline). 

Additional  feature  types  are  needed,  including  navigable  rivers,  major 
cities,  lakes,  airfields,  major  roads,  railroads,  ports;  there  should  be 
a  distinction  between  river  mouths  and  shorelines. 

Software  to  translate  WS  to  VDB  TI  should  b°  developed. 

Instructions  for  converting  programs  from  WDB  II  to  WS  input  should  be 
provided . 

Shorelines  to  the  north  and  south  of  the  65  degree  parallels  are  needed. 

Links  between  segments  broken  at  cell  boundaries  would  be  helpful. 

In  this  year's  Naval  DMAP  meeting,  Landrum  (1989)  discussed  on-going  MC&G 
product  evaluations,  many  of  which  have  been  based  on  NORDA’s  evaluation  of 
WVS.  Future  Navy  requirements  for  the  VVS  database,  including  those  listed 
in  this  paper,  are  being  addressed  by  the  Naval  DMAP.  In  addition,  the 
entire  VVS  database  will  be  stored  in  the  DMAP  software  library  at  NORDA,  for 
ready  access  by  interested  Navy  users.  More  information  about  the  DMAP  software 
library  may  be  found  in  Current  (1989). 


SUMMARY 

DMA  and  NORDA  combined  forces  to  design  a  data  structure  and  format  for 
the  VVS  that  would  best  meet  users'  needs.  The  new  WS  database  meets  Navy 
requirements  as  listed  in  the  1985  CNO  OP-096  memo,  ser  006C/50322906 ,  and 
as  summarized  at  the  start  of  this  report.  Potential  Navy  users  were  given  a 
copy  of  the  new  VVS  prototype  to  evaluate,  along  with  a  questionnaire  that 
addressed  such  issues  as  computer  system  limitations,  WS  applications,  and 
eqirements.  Overall,  users  responded  very  favorably  to  the  yvs  database, 
and  offered  many  suggestions  for  future  work.  The  most  critical  future  needs 
for  WVS  have  been  listed  in  this  paper. 
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